SDN is an emerging framework which includes a centralized control plane decoupled from the data plane. Conventionally, SDN works with a central controller knowing a full network topology through configuration or through use of a controller-based discovery process. The controller differs from a management system in that it controls the forwarding behavior of the switch only, and performs control in real time or near real time, reacting to changes in services requested, network traffic analysis and network changes such as failure and degradation. Also, the controller provides a standard northbound interface to allow applications to access network resource information and policy-limited control over network behavior or treatment of application traffic. The controller sends commands to each network switch to control matching of data flows received and actions to be taken, including any manipulation of packet contents and forwarding to specified egress ports. Egress ports on each network switch are assumed to be fixed to connect directly with a remote switch. The controller may use commands to change characteristics of the egress port, but cannot change the remote endpoint that the port connects to. Connections are made by having the controller issue commands to a series of network switches, configuring their flow tables to forward data from the ingress port on the source switch to the desired destination switch and egress port. Examples of this type of software defined network control include OpenFlow (www.opennetworking.org/sdn-resources/onf-specifications/openflow/), General Switch Management Protocol (GSMP) defined in RFC 3294 (June 2002), and Forwarding and Control Element Separation (ForCES) defined in RFC 5810 (March 2010), the contents of all are incorporated by reference herein.
There are various shortcomings of these conventional SDN approaches. First, there is limited control and flexibility—once the controller has been informed of the topology, either by configuration or by controller-based discovery, this topology does not change even if traffic patterns change. The controller is only able to redirect data flows within the fixed topology. Second, there is a heavy process load on the controller. Specifically, the controller is responsible for contacting each switch in the network in order to set up flows and to discover the overall network topology. The system cannot take advantage of any local intelligence on the switch in order to offload processing from the controller. Third, there is the involvement of the controller in any recovery actions—in order to recover from a failure, the controller must be involved in the rerouting of all connections that have been affected by the failure, causing an instantaneous spike in load on the controller when a failure occurs. Failure of the controller must be avoided by high availability design of the controller and high redundancy and performance of the control network to support messaging between each switch and the controller. Finally, there is a requirement to convert every network node over to a centralized control scheme—in order for the system to work, every node in the network must be converted over to software defined control from the controller, regardless of any pre-existing control mechanism.